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REMARKS/ARGUMENTS 

Claims 1 remains in the application. Claim 2 has been cancelled. New claims 3-11 
have been added. No new matter has been added. 

Applicant gratefully acknowledges the courtesy of the interview granted to 
Applicant's representative, Dr. Jon L.Roberts, on August 17, 2007. 

Claim Rejections - 35 USC 103 

Claims 1-2 were rejected as allegedly being obvious in view of the published 
application of Arunapuram et al. Applicant traverses this rejection. 

As a whole, Arunapuram et al. is drawn to optimization of a shipping process, and 
is not concerned with monitoring an existing process and taking action when a process 
exception occurs, i.e., an event that is unusual and would benefit from human 
involvement by the process owner. In Arunapuram et al. , status information from the 
Crossdocks 314, Warehouses 316, Distributors 312, and Carriers 322 are part of the 
process itself, such that there is no additional monitoring or processing other that what 
was already part of the existing shipping process. In the present invention, a process is 
identified and then additionally monitored for process exceptions. 

According to the Office Action, 3 paragraphs (0046-0048) of Arunapuram et al. 
disclose a method and apparatus for using process exceptions to provide instant 
notification for distributed processes. The Office Action alleges that status information 
from Crossdocks 314, Warehouses 316, Distributors 312, and Carriers 322 are 
information sources that are detected by shipment status interface 406, the shipment 
status interface 406 processes the stimulus to generate an exception in the form of an 
alarm, and communicates the exception/alarm to a message controller in the form of the 
customer status interface 408. However, shipment status interface 406 does not process 
information or send messages to customer status interface 408 (these steps are done by 
EX module 400). Indeed, rather than detecting process exceptions, and transmitting them 
to messaging controllers over primary and alternate communication mechanisms, as a 
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whole, Arunapuram et al. merely discloses the automatic processing of shipping status by 
a transportation manager program or module (i.e., EX module 400). 

According to Arunapuram et al. , "the execution module 400 contains a shipment 
status interface 406 for use by the carriers 322 (both external and internal), warehouses 
316, crossdocks 314 and distributors 312. The information transferred into the execution 
module 400 via shipment status interface 406 conveys information about shipments that 
are scheduled for delivery or en route including when the carrier expects the route to 
leave, when the route has left a distribution center, when the route has arrived at a 
particular crossdock or warehouse, as well as expected delays either at the carrier end 
or at the location end. The execution module 400 is able to use this shipment status 
information to provide updates to customers 320 or sales offices 318 via the customer 
status interface 408 as shown" and "The EX shipment status interface 406 as depicted in 
FIG. 4 delivers shipment status messages to the EX module 400 from carriers 322, 
distributors 312, warehouses 316, and crossdocks 314, etc., regarding a load or shipment 
while the load or shipment is en route. These status messages can include update 
information such as expected early or late arrivals, on time shipments received, or 
shipment completed and/or cancelled. When such messages are sent in real time from a 
carrier, these messages can be used to control alarm generation within the EX module 
400. Such alarms, for example, can be used to send shipment status notifications to a 
transportation manager 309 via manager interface 404, or to sales offices 318 or to 
customers 320 via the customer status interface 408." 

Since all of the actions referred to by the Office Action occur within a single 
module or program, there would clearly be no need for a secondary communication 
mechanism . In fact, it is unclear whether an internal computer bus running the EX 
module would even qualify as the first or primary communication mechanism within the 
broadest reasonable interpretation consistent with the specification (see MPEP 2111), 
which lists communication mechanisms as external communication mechanisms such as 
a local area network, the Internet, a modem, mobile phones, satellite, or pagers. 
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In view of this, it is clear that there would be no reason (absent impermissible 
hindsight) to provide Arunapuram et al. with a secondary communication mechanism as 
suggested by the Office Action. 



New Claims 

New claims 3-6 depend on allowable process claim 1 and are allowable as being 
dependent on an allowable claim. New claims 7-11 are system claims that are meant to be 
coextensive with the process claims 1 and 3-6 and are allowable for the same reasons. 



Conclusion 

For the reasons cited above, Applicant submits that claims 1 and new claims 3-11 
are in condition for allowance and requests reconsideration of the application. If there 
remain any issues that may be disposed of via a telephonic interview, the Examiner is 
kindly invited to contact the undersigned at the local exchange given below. 

Respectfully submitted, 

/Christopher B. Kilner/ 

Christopher B. Kilner 

Registration No. 45,381 

Jon L. Roberts, 

Registration No. 31,293 

Roberts Mardula & Wertheim, LLC 

11800 Sunrise Valley Drive, Suite 1000 

Reston, VA 20191-5302 

(703) 391-2900 
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